Algebraic Modeling of Diagnostic Problems in Hw-Sw Codesign

The widespread use of embedded controllers in dependability-relevant products requires a radical increase both in the productivity and in the quality of the overall design process, thus necessitating the automation and the integration of the functional and diagnostics design processes. Recently, the most e ective system design methodology is hardware-software codesign, supporting a uni ed modeling of hardware and software at the highest level of abstraction, hierarchical step-wise model re nement, and nally, automatic silicon and software synthesis. Dataow network (DFN) based modeling is the most widely used paradigm in the initial phases of the hardware-software codesign process, as it provides a user-friendly graphic interface for the practitioner engineer with an exact mathematic formalism in the background. The DFN model of the system is composed of nodes (functional elements) interconnected by unidirectional channels. The presence and ow of data items across the system are represented by tokens, moving along the channels. A node starts its computation, when a su cient number of tokens is present in its input channels as prescribed by some of its ring rules. If multiple rules of the same node are simultaneously in a reable state, then the actually red one can be selected either by a prede ned priority scheme or by a random choice, similarly to the Petri-nets. Tokens are produced on the output channels and the node enters a new state after ring. 1 Uninterpreted DFNs are used at the highest level of abstraction to model the dynamics of the ow of data between the individual functional elements of the system under design. Only the presence of data is modeled at this level, in the form of so-called simple or un-coloured tokens. Data dependencies are either neglected, or represented only by a non-deterministic behavior of the corresponding element. (Note, that in the ring rules of the individual DFN nodes, non-unique mappings formulated as relations can be used instead of the more restrictive class of functions.) Interpreted DFNs use di erent types of tokens in a similar way, as coloured Petri-nets do it. Interpreted modeling is typically used during the functional design process for the ne granular modeling of the target system, including the description of data dependencies. Naturally, this high level of model realism results in a huge computational complexity in the evaluation phase. However, the main intention of approach was to provide a support to the designer during the architecture design phase in such typical decisions, as which components have to be replicated in order to assure a system level fault tolerance etc. Accordingly, the domains of the token types are kept very limited. For instance, tokens can be coloured either as correct or as erroneous according to the fault state of the informa-